Hard requirement: 100% test coverage for the new Bank Frick code

This PR touches inbound statement import and outbound fiat payouts — money movement with double-spend exposure. For this surface, 100% test coverage of the new Bank Frick code is a hard requirement (statements, branches, functions, lines) before it can be considered ready. Nice-to-have paths and defensive throw branches are explicitly in scope — on payout code the fail-closed guards are exactly what must be proven.

The current suite is genuinely strong on the critical happy/error paths (RSA-exact-bytes signing, JWT cache + single 401 retry, fail-closed camt parsing + non-advancing watermark, idempotent-payout collision check, liquidity reservation). But coverage is not yet 100%, and right now nothing enforces it: there is no coverageThreshold, and CI runs jest --silent without --coverage, so the green checks say "tests pass", not "code is covered".

1. Make it enforceable (so it can't silently regress)

• Add a coverageThreshold of 100% for the new Bank Frick files (branches/functions/lines/statements) to the Jest config.
• Run coverage in CI (test:cov / jest --coverage) so the threshold is actually a gate. Without this the requirement is invisible and drift creeps back in.

2. Close the current gaps

Concrete branches/paths that still need tests:

fiat-output-job.service.ts (the finalizing state machine — highest priority):

• getFrickStatusUpdate: the BOOKED and EXECUTED transitions and the default "Unsupported Bank Frick payment state" throw
• checkFrickOrderStatus: the auto-approval branch, the isAvailable/DisabledProcess guards, and the IN_PROGRESS/EXECUTED/BOOKED updates
• both catch blocks ("FRICK error" in transmitFrickPayments, "FRICK status error" in `checkFrickOrderStatus")
• charge mapping BEN/OUR/SHA
• createBatches Frick exclusion exercised with an actual Frick entity

frick.service.ts:

• the approveWithoutTan-not-enabled throw in isolation (today the payoutEnabled check short-circuits it, so this guard is never asserted on its own)
• getPaymentOrder at unit level, including the not-found throw
• the validation throws: validateAmount, IBAN/BIC/customer validation, validateTransactionsResponse/validateAccountsResponse invalid branches, parseResponseAmount European-format path
• JWT edge cases: exp === undefined → Infinity, malformed-JWT throw
• the SEPA_INSTANT path + the "instant only EUR" throw
• the moreResults ambiguity throws
• getSafeOrderId positive path

bank-tx.service.ts — checkFrickTransactions guards:

• getBanksByName / getMultiAccounts throw handling, banks.length === 0, invalid bank.id

iso20022.service.ts: the value-date branch of assertValidCamtDate (only the booking branch is covered)

config.ts: the FRICK_PRIVATE_KEY <br> → \n transform (tests currently set the PEM directly)

Once the threshold is in place and green, the 100% number is self-documenting and this requirement is met.

Follow-up: the coverage gate is in place but scoped too narrowly

Thanks for wiring up the enforcement — coverageThreshold: 100 plus the new CI step Enforce Bank Frick coverage (test:frick:cov) is exactly the right mechanism, and it addresses the "nothing enforces it" part of the earlier requirement.

The remaining gap: the gate only covers two of the new Frick files. Both the coverageThreshold block and the --collectCoverageFrom flags in test:frick:cov list only:

• src/integration/bank/dto/frick.dto.ts
• src/integration/bank/services/frick.service.ts

and the script runs only frick.service.spec.ts. So the gate proves 100% on the Frick client, but the following new Frick code is not in the threshold and not measured — including the highest-risk surface:

The hard requirement was 100% of the new Bank Frick code, and it's precisely the payout finalizing state machine (fail-closed guards on money movement) that most needs to be locked down. Please extend both the coverageThreshold map and the collectCoverageFrom set (and the executed spec files) to include the four files above, so the gate covers the whole surface rather than just the client.

Round 2 addressed: full-surface coverage gate + all review suggestions

Thanks for the precise follow-up — the gate scope and every suggestion from the review are now implemented as of 0ae471757.

Coverage gate (the hard requirement). Rather than adding the four shared files wholesale to the threshold map — config.ts and bank-tx.service.ts carry large pre-existing uncovered legacy surfaces (~40–95% uncovered) that a "Bank Frick" gate should not absorb — the new Frick code was isolated into dedicated files so the gate measures exactly the surface you listed:

coverageThreshold and test:frick:cov (run by the existing CI step) now enforce 100% statements/branches/functions/lines on all six Frick files (frick.dto.ts, frick.service.ts, iso20022.service.ts, frick.config.ts, bank-tx-frick.service.ts, fiat-output-frick.service.ts) — 168 focused tests. Delegation residues left in the original files are DI wiring and one-line calls only.

Suggestions and nit:

• fromDate (47e428967): every transactions?customId= lookup now sends fromDate=1970-01-01, and the unit tests assert it on both the active and the BOOKED lookup.
• DELETION_REQUESTED (9293d249a): removed from the terminal set — liquidity stays reserved and polling continues until DELETED/REJECTED/EXPIRED/ERROR (or a matching debit bankTx); re-approval is asserted to never fire outside PREPARED.
• Approval decoupling (3a428229b): isFrickAutomaticApprovalEnabled no longer references FIAT_OUTPUT_FRICK_TRANSMISSION; process gating is the caller's job (FIAT_OUTPUT_FRICK_STATUS_CHECK for the status job). Tested: transmission disabled + status check enabled still approves a PREPARED order.
• Watermark overlap (7cdc9bba4): advances to max(previous, min(now, max bookingDate) − 2d) — monotonic, empty responses still advance (no epoch refetch on idle accounts), and the 2-day overlap deliberately re-fetches recent history with duplicates absorbed by the accountServiceRef dedup. Backfill runbook added at docs/bank-frick-operations.md.
• Raiffeisen/Yapeal one-time duplicates: monitoring and cleanup guidance documented in the same runbook and referenced from the PR description.
• validateCustomer (a9195fbc1): tightened to the documented OpenAPI bound ^\d{1,7}$ so misconfiguration fails closed at the config check.

Validation for 0ae471757: format/lint/type-check/build green, full local Jest run 160 suites / 2,535 tests passed (7 infrastructure-dependent suites skipped locally, they run in CI), test:frick:cov green at 100% on all six files.

⚠️ Unverified Commits (5)

The following commits are not signed/verified:

• 5129342 fix: apply Ultra Test-Agent repair for PR feat(bank): integrate Bank Frick WebAPI #4196 (Ultra Test-Agent Fixer)
• 5133363 fix(bank): resolve Bank Frick deep-review findings (joshuakrueger-dfx)
• d3200b8 fix(bank): address re-review findings in the Bank Frick fix commits (joshuakrueger-dfx)
• 7c86a87 style(bank): wrap payment observer spec helper signature for prettier (joshuakrueger-dfx)
• 6af3006 chore(bank): isolate the Bank Frick coverage gate in its own jest config (joshuakrueger-dfx)

# SSH signing (recommended)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# Re-sign last commit
git commit --amend -S --no-edit
git push --force-with-lease

Follow-up: repo precedent for bank rows — sharpens findings #2 and #3

I went back through the history for how bank rows have actually been added in this repo, because my fix proposals should follow the existing convention rather than invent one. Two things came out of it, one of which corrects the framing of my own review.

bank rows are inserted manually in production, never by a migration

There is exactly one precedent, and it was explicitly reverted:

• 9a47168e1 feat(bank): add Yapeal EUR manual bank account CH8383019496938261612 added migration/1768943778000-AddYapealEurManualBank.js, which did INSERT INTO "bank" (…) VALUES ('Yapeal', 'CH8383019496938261612', 'YAPECHZ2', 'EUR', 0, 1, 0, 1, 405).
• It was then removed again by f897b98a2 chore: remove migration (already inserted manually).

So the settled practice is: the row is created manually in production, and no migration touches the bank table. migration/1783944000000-AddBankFrickPayoutTracking.js is currently the only migration in the repo that inserts into bank — verifiable with grep -ri 'insert into "bank"' migration/.

That is the strongest argument for the fix I proposed in #2/#3, and it is a cleaner one than the reasoning I gave: drop the INSERT INTO "bank" from the migration entirely. Keep the fiat_output columns and the disabledProcess seeding — those genuinely belong in a migration — and let the two new Frick rows be created in production the same way the Yapeal EUR row was. That removes the fabricated IBANs from production, removes the public-endpoint exposure in #3, and removes the impossible "replace each synthetic IBAN" step from §3 of the runbook, all at once. It leaves finding #2 (the legacy rows) as the only thing still needing a decision.

The IBANs are not secret, and treating them as secret was my inconsistency

I deliberately withheld the real IBANs from my first review. That was wrong by this repo's own convention, and I want to correct it rather than quietly keep doing it:

• migration/seed/bank.csv already carries the real Olkypay, Raiffeisen and Maerki Baumann IBANs in plaintext.
• The real Yapeal EUR IBAN is in a commit subject line (9a47168e1).
• Every bank IBAN is served by GET /v1/bank, which is unauthenticated — that is by design, since customers need to know where to transfer.

There is therefore no reason to encode a placeholder. The new Bank Frick account (a different account from the old, removed integration — the legacy rows in #2 carry the old account's IBANs) is:

• EUR: LI75088110105923K000E
• CHF: LI32088110105923K000C

Both are mod-97 valid and follow the same Frick structure as the existing rows (08811 010 + account + K000 + currency letter). These should go into migration/seed/bank.csv for fresh/dev databases — where the file already mixes real IBANs for Olkypay/Raiffeisen/Maerki with synthetic ones for Yapeal, and the real ones are the better convention — with receive/send/sctInst staying FALSE until sign-off. The flags are the safety mechanism, not a fake IBAN. Production gets the rows manually, per the precedent above.

Nothing else in the review changes.

Correction to my previous comment: the seed CSV should stay synthetic

One thing in my follow-up was wrong, and I would rather correct it than leave a bad instruction standing in the thread.

I suggested putting the real Bank Frick IBANs into migration/seed/bank.csv. Ignore that. The seed file is example data for fresh/local databases — synthetic placeholders are exactly what belongs there, and this PR already does that correctly. No change needed in bank.csv (beyond the id 17/18 collision noted in #3). That the file happens to carry real IBANs for some older banks is incidental history, not a convention worth propagating.

So the corrected position is narrower than what I wrote, and it isolates the actual defect:

• migration/seed/bank.csv — synthetic placeholders. Correct as-is in this PR. ✅
• migration/1783944000000-AddBankFrickPayoutTracking.js — must not insert bank rows at all. This is the one thing to change. Precedent: 9a47168e1 added a migration to insert a Yapeal bank row and it was reverted by f897b98a2 chore: remove migration (already inserted manually); no migration in the repo inserts into bank. Production rows are created manually, with the real IBANs, and never travel through the repo.

That keeps the fabricated IBANs out of production (and out of the unauthenticated GET /v1/bank) without putting real account data into an example file. Findings #1–#12 are otherwise unchanged.

Closing the seed-CSV point: align the placeholders with the Yapeal pattern

To settle this concretely rather than leave it as an opinion, here is what migration/seed/bank.csv actually contains today, checked line by line against the live registry:

So it is 4 real / 4 synthetic, but that split is misleading: the four real ones are stale rows filed under the wrong bank name. They are not a convention to follow. The two rows that are actually maintained and correctly named — Yapeal, the closest analogue to Frick — are synthetic. Synthetic placeholders are right, and this PR is right to use them.

There is one detail worth aligning, though. The Yapeal placeholders keep the real bank clearing number and only fake the account part:

CH67 | 83019 | DFXEUR000002      83019 = Yapeal's real clearing number

The Frick placeholders zero that out too (LI56 | 00000 | FRICKEUR0001), so they do not resemble a Bank Frick IBAN at all — the real ones are LI.. | 08811 | …K000E. Keeping the real institution prefix is what makes a placeholder useful in dev: BIC/IBAN-consistency checks and any prefix-based routing behave like production.

Consistent with Yapeal:

18,…,Bank Frick,LI17088110FRICKEUR001,BFRILI22,EUR,FALSE,FALSE,FALSE,TRUE,
17,…,Bank Frick,LI35088110FRICKCHF001,BFRILI22,CHF,FALSE,FALSE,FALSE,TRUE,

Both are mod-97 valid, 21 chars (correct LI length), carry Frick's real clearing number 08811, and remain unmistakably synthetic. The ids 17/18 are fine as they are — the seed file has its own id space (next free after Yapeal's 15/16); disregard the id-collision remark in my earlier comment, which compared them against production ids that this file never sees.

This is cosmetic and does not affect any of findings #1–#12. The substantive point next door stands unchanged: the migration should not insert bank rows at all (precedent f897b98a2 chore: remove migration (already inserted manually)), and the production rows carry the real IBANs of the new account, created manually.

Re-review of the fix commits (77eb99e13 → 5133363d8)

I re-reviewed the two follow-up commits (512934223, 5133363d8 — 28 files, +1842/−367) against my earlier findings. Method: regression-verify each of the 24 prior findings at the new head, plus a fresh adversarial sweep over the genuinely new surface (the sendPriority mechanism, frick-mock-gateway.ts, the bank.adapter FRICK case, the payment.observer change, and the cross-file column renames), every candidate then checked by three independent lenses. Prod-data claims below are verified against the live DB.

This is a strong round of fixes. The blocker and the large majority of the prior findings are genuinely resolved, not papered over. But the ~1800 lines of fix code introduced four new defects, three of them major, and one of those trips on production data the day this merges — before Frick is even enabled. Fix commits are unreviewed code; that is exactly where these landed.

Confirmed resolved (verified at head, not just claimed)

• B1 (blocker) — sender-routing throw. Replaced by the bank.sendPriority tie-breaker; the throw now fires only for a genuine top-priority tie that includes Frick, never for an Olkypay/Yapeal tie at the shared default. Migration backfills every existing row to 1000; the runbook inserts the manual Frick rows at 2000 with the real IBANs. An EUR payout still routes to Olkypay with Frick send=true. Resolved.
• M2/M3 — migration. Now schema-only: no bank INSERT/UPDATE/DELETE, no FK, only the fiat_output columns, bank.sendPriority, and the setting DML. The two Frick rows are a documented manual production step, matching the Yapeal precedent. Resolved.
• M4 — one bad camt.053 entry. Per-entry onEntryRejected + fullyParsed flag; a single bad entry drops just that entry and the watermark refuses to advance past a partially-parsed window, while an account-IBAN mismatch stays fatal. Resolved.
• M5 — reference-less dedup. Strict mode now throws missing bank reference instead of hashing the payload, so a bank-side amendment can no longer re-import the same credit. Resolved.
• M6 — double payout. Atomic reserve update({ id, frickCustomId: IsNull() }, { frickCustomId }) with if (reserved.affected !== 1) continue before the PUT — a proper WHERE-clause mutex, and object-form (not a raw () => 'expr'), so the Postgres RHS-quoting trap does not apply. Resolved for the double-payout case (but see NEW-2 below for a stranding it introduced).
• M7 — BOOKED lookup. validateTransactionsResponse(…, requireTypeAndCustomId) relaxes the customId-scoped lookup so a settled BOOKED order resolves instead of throwing. Resolved.
• M8 — charged debit reconciliation. chargeAmount now parsed (not hard-coded 0) and the matcher compares amount − COALESCE(chargeAmount,0). Reconciliation resolved (but see NEW-3 for the accounting-side contradiction it exposes).
• M9 — liquidity balance never refreshed. bank.adapter.ts now has a FRICK case wiring getBalances(), mirroring YAPEAL, with a fail-loud on a missing availableBalance. Resolved.
• M10 — send=true/receive=false deadlock. Bank.isReconcilable getter, and it is actually called (bank-tx-frick.service.ts:44) to log a loud per-cycle error; runbook §3 documents the receive=true requirement. Detection resolved (it alerts rather than hard-blocks — a defensible choice).
• M11 — terminal failure erased. Reason now preserved (frickError ?? 'Bank Frick order terminated: <state>') and surfaced by the observer. Resolved.
• M12 — remittanceInfo overwrite. New frickReference column holds the bank-bound reference; remittanceInfo is only backfilled when empty, never overwritten; the matcher reads frickReference ?? remittanceInfo. Resolved.
• m13–m16, m21, m23, m24 — instant-CHF gated to EUR; signature now verified over raw Buffer (arraybuffer); distinct FrickSignatureVerificationError; HTTP_TIMEOUT_MS; mock extracted to a typed instance-scoped FrickMockGateway; frickCustomId/frickReference/frickOrderId(64) renamed; dead getSenderBank() removed. Resolved.

Two prior minors remain unaddressed (not regressions, just untouched): m22 the 100% coverageThreshold still sits on the shared iso20022.service.ts, and m19 no test exercises the new SQL against a real Postgres (the migration spec mocks queryRunner). Both are minor.

NEW defects introduced by the fix commits

NEW-1 (major) — the observer fix flips /health to DEGRADED on deploy, from pre-existing non-Frick rows

src/subdomains/core/monitoring/observers/payment.observer.ts:126

The M11/m18 fix widened stuckFiatOutputs from a single condition to an OR of three clauses. Clause 3 — { isTransmittedDate: LessThan(Util.hoursBefore(48)), isComplete: false } — has no bank or type scope; it counts every fiat_output across all banks. health.controller.ts:149 raises DEGRADED whenever stuckFiatOutputs > 0, and that propagates to GET /health and /health/payment.

Verified against production today: the base clause matches 0 rows (health is OK now), but clause 3 already matches 4 pre-existing, non-Frick rows (2× BuyFiat, 1× BankTxReturn, 1× BuyCryptoFail — Olkypay/Yapeal, transmitted months ago, never reconciled, isComplete=false). So the moment this merges — with zero Frick activity — stuckFiatOutputs jumps 0 → 4 and /health reads DEGRADED permanently, growing as more non-Frick payouts age past 48h. A permanently-degraded signal masks real incidents and desensitises operators to the very Frick terminal-state alert (clause 2) this change adds.

Fix: scope clause 3 to Frick (frickCustomId: Not(IsNull()), or bank: { name: FRICK }), leaving cross-bank reconciliation-gap monitoring to a separately-designed metric; or close the 4 standing rows so the baseline is truly 0 before widening a shared health metric.

NEW-2 (major) — the M6 reserve strands reconciliation if the post-create persist fails

src/subdomains/supporting/fiat-output/fiat-output-frick.service.ts:120

transmitPayments atomically reserves only frickCustomId, then calls createPaymentOrder, then persists frickReference / isTransmittedDate / remittanceInfo in a separate update (:152-159). frickReference is deterministic and already computed at :97, before the reserve — but it is not folded into the atomic write. If that second update fails transiently (DB blip) or the pod restarts after the bank call succeeds, the row is left with frickCustomId set but frickReference = NULL and isTransmittedDate = NULL, while the order exists at the bank and the money moves. The self-heal in checkFrickOrderStatus only clears on FrickPaymentOrderNotFoundError; here the order is found, so frickReference is never re-derived. transmitPayments skips the row (frickCustomId set), and reconciliation keys on frickReference ?? remittanceInfo — both NULL → the bank-echoed debit can never match → isComplete never set → liquidity stranded indefinitely. That is precisely the deadlock class this PR set out to remove, reachable through a narrower window.

Fix: fold frickReference into the atomic reserve ({ frickCustomId: customId, frickReference }, both already known at :97), and/or have checkFrickOrderStatus re-persist frickReference/isTransmittedDate when it finds an existing order on a row missing them.

NEW-3 (major) — charge sign is inconsistent between reconciliation and accounting

src/subdomains/supporting/bank-tx/bank-tx/services/bank-tx.service.ts:273

The M8 fix makes Frick debits carry a real chargeAmount, and the outgoing matcher reconciles net of it (ABS((amount − COALESCE(chargeAmount,0)) − :instructed)), which only succeeds if the booked debit amount is charge-inclusive (gross = instructed + charge). But the pre-existing accounting path does the opposite: accountingAmountBeforeFee = amount + chargeAmount (and the BUY_FIAT branch accountingAmountAfterFee = amount + charge), treating amount as charge-exclusive. Both fire on the same row — a Frick BUY_FIAT payout debit is typed BUY_FIAT and fillBankTx's where: { chargeAmount: Not(IsNull()) } selects it. Before this PR Frick emitted chargeAmount = 0, so the two conventions never disagreed; the charge parsing newly activates the contradiction. A 100-CHF payout booked gross as 105 (charge 5) reconciles correctly (105−5 = 100) but is accounted as 105 + 5 = 110 — overstated by the charge on every charged Frick FOREIGN payout.

Fix: make the sign convention consistent for outgoing/debit entries — don't add chargeAmount again in accounting for debits (gate amount + chargeAmount to CREDIT entries, or subtract for DEBIT). Which of the two interpretations is correct must be confirmed against a real charged-payout CAMT from the Frick sandbox (this is already on the PR's activation-blocker list), and both paths aligned to it.

NEW-4 (minor) — self-heal race can blind the status poller

src/subdomains/supporting/fiat-output/fiat-output-frick.service.ts:56

fillFiatOutput (EVERY_MINUTE → transmitPayments) and checkFrickOrderStatus (EVERY_HOUR) get separate cron locks (dfx-cron.service.ts:54), so they can overlap. In the ~seconds-to-30s window after transmitPayments reserves frickCustomId but before the bank PUT lands, the hourly job can call getPaymentOrder → not-found → and, because its stale snapshot has isTransmittedDate = NULL, unconditionally clear frickCustomId. transmitPayments then completes the order at the bank but leaves frickCustomId NULL, so the dedicated poller (which requires frickCustomId Not null) never polls it again — a failed payout goes untracked for up to 48h. No double payout (idempotent customId + isTransmittedDate guard), but the "durable reservation" invariant is violated.

Fix: make the clear conditional — update({ id, frickCustomId: entity.frickCustomId, isTransmittedDate: IsNull() }, { frickCustomId: null, frickError: null }) — or re-load and re-check immediately before clearing.

Raised but dropped (2 of 3 verifiers refuted)

I flagged the CHF charge ?? SHA default (fiat-output-frick.service.ts:106) as a lingering silent-money-fallback (my prior m17). On adversarial re-check I'm withdrawing it: charge is a SWIFT charge-bearer code (BEN/OUR/SHA), not a money amount, and DFX already hard-codes SHA for outgoing payments elsewhere (iso20022.service.ts:650), so defaulting to SHA is an established, consistent policy rather than a masked wrong value. The fix additionally makes it durable and visible. Not a defect.

Verdict

The blocker is gone and the money-path and CAMT findings are properly fixed — this is close. What's left is that the fixes themselves need the same scrutiny the original code got: NEW-1 is the one to resolve before merge (it degrades a shared production health signal on deploy, independent of Frick, and I've confirmed it against live data), and NEW-2/NEW-3 should be fixed before the rail is activated. NEW-3 in particular can't be fully settled from the repo — it needs the real charged-payout CAMT the sandbox validation will produce.

(Method note: my automated verification pass completed the regression check of all 24 prior findings and the fresh sweep; a final completeness-critic stage aborted on an infra error, so this round did not get the extra round-2 depth the first review had. The four findings above each cleared three-lens verification and, where they touch production state, direct DB checks.)

Addressed the re-review of the fix commits (5133363d8 → 7c86a87da) and ran a final review over the complete PR diff.

The four new defects the re-review found in the fix commits are resolved:

• NEW-1 — the stuckFiatOutputs health clause is now scoped to Bank Frick (frickCustomId not null), so a deploy no longer flips /health to DEGRADED from pre-existing, long-settled non-Frick payouts.
• NEW-2 — frickReference is folded into the atomic payout reservation (and re-healed in the status poller when an order is found on a row still missing it), so a crash between the two writes can no longer strand reconciliation.
• NEW-3 — the accounting charge is now direction-aware (a debit amount is treated as gross, matching the net-of-charge outgoing reconciliation), removing the double-count on charged Bank Frick payouts.
• NEW-4 — the not-found self-heal clear is conditional (WHERE frickCustomId = <observed> AND isTransmittedDate IS NULL), so an overlapping transmit can no longer blind the status poller by clearing a just-reserved row.

Each fix has a regression test that fails against the pre-fix code. Full suite green, Bank Frick coverage stays at 100%, and the final review over the whole PR found no outstanding correctness or conformity issues.

One item to confirm before merge/activation — accounting field only, no money flow or double-payout: NEW-3 and #8 both rest on the assumption that Bank Frick books debit entries gross (charge-inclusive), which is already on the activation checklist for sandbox confirmation. Because the accounting change (amount + chargeAmount → gross for debits) lives in the shared fillBankTx, it also applies to any legacy SEPA-file debit that carries a parsed charge (SepaParser.getTotalCharge). Please confirm the gross/net convention for those legacy debits — if any were historically booked net, their accountingAmountBeforeFee would need the charge kept. No payout amount or reconciliation outcome changes; this is the internal accounting figure only.

Follow-up consistency improvement (7c86a87da → 6af30068d).

Isolated the Bank Frick 100% coverage gate into its own jest.frick.config.js (used only by test:frick:cov), out of the shared package.json jest block. This addresses the earlier note that a strict per-file threshold on the shared iso20022.service.ts would otherwise red an unrelated test:cov run — no other bank integration ships a coverage gate in the shared config.

Behaviour-neutral for the Frick gate: same seven files, same 100%, enforced in the same CI step. Verified directly — dropping a covered spec still reds the gate (iso20022.service.ts → 57.72% → threshold not met), and test/test:cov no longer carry the per-file requirement. No production code changed; the new root config is added to eslint ignores alongside the existing root configs.

A separate dead-guard cleanup was considered and deliberately not taken — that guard turned out to be a tested defense-in-depth layer on the reconciliation path, so it was kept.